【Security Hub修復手順】[EC2.19] セキュリティグループは、リスクの高いポートへの無制限アクセスを許可してはいけません

【Security Hub修復手順】[EC2.19] セキュリティグループは、リスクの高いポートへの無制限アクセスを許可してはいけません

AWS SecurityHub 基礎セキュリティのベストプラクティスコントロール修復手順をご紹介します。
Clock Icon2022.11.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは!AWS事業本部のおつまみです。

皆さん、お使いのAWS環境のセキュリティチェックはしていますか?

当エントリでは、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修正手順をご紹介します。

本記事の対象コントロール

[EC2.19] セキュリティグループは、リスクの高いポートへの無制限アクセスを許可してはいけません

[EC2.19] Security groups should not allow unrestricted access to ports with high risk

前提条件

本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容となります。 AWS Security Hubの詳細についてはこちらのブログをご覧ください。

対象コントロールの説明

このコントロールは、AWS側で指定された高リスクのポート(22,3389番ポートなど)にセキュリティグループの受信 SSH トラフィックがアクセス可能かどうかをチェックします。
セキュリティグループ内のルールがこれらのポートへの 0.0.0.0/0 からの入力トラフィックを許可しない場合、このコントロールは成功します。

無制限のアクセス (0.0.0.0/0) では、ハッキング、サービス拒否攻撃、データ損失などのセキュリティリスクが発生してしまいます。可能な限りコントロールを修正しましょう。

修正手順

1. ステークホルダーに確認

  1. まずはステークホルダー(リソースの作成者や管理している部署などの関係者)に以下を確認します。
  • 以下のポートで接続するユーザーが存在するか確認する。
    • 20、21 (FTP)
    • 22 (SSH)
    • 23 (Telnet)
    • 25 (SMTP)
    • 110 (POP3)
    • 135 (RPC)
    • 143 (IMAP)
    • 445 (CIFS)
    • 1433、1434 (MSSQL)
    • 3000 (Go、Node.js、および Ruby のウェブ開発フレームワーク)
    • 3306 (mySQL)
    • 3389 (RDP)
    • 4333 (ahsp)
    • 5000 (Python ウェブ開発フレームワーク)
    • 5432 (postgresql)
    • 5500 (fcp-addr-srvr1)
    • 5601 (OpenSearch Dashboards)
    • 8080 (proxy)
    • 8088 (レガシー HTTP ポート)
    • 8888 (代替 HTTP ポート)
    • 9200 または 9300 (OpenSearch)
      • 存在する場合、接続元のIPアドレスを絞っておく必要があります。 そのため、接続元のIPアドレスを特定して下さい。

        • どうしてもIPアドレスを絞ることができず0.0.0.0/0で公開する必要があるとステークホルダーに判断された場合、そのEC2に侵入されても被害が少ないというリスクの判断ができる、かつそれを許容できている場合に0.0.0.0/0を許可して下さい。それ以外、許容すべきではないため抜本的に見直しましょう。
      • 存在しない場合、[3.設定削除]を実施して下さい。

    ※ 設定削除後に該当ポートで接続できなくなります。万一、設定が必要だった場合に、業務影響が出てしまいます。そのため、社内で注意深く確認して下さい。

今回はセキュリティグループのインバウンドルールで送信元0.0.0.0/0のSSH(22)が空いていたと仮定します。

2. 設定追加

1.AWS マネージメントコンソールを開きます。 2.ヘッダーナビゲーションのサービス検索より「VPC」を検索し、選択します。
※リージョンは「東京」を選択します。東京リージョン以外の他リージョンも使用している際は確認して下さい。

3.左ペインより[セキュリティグループ]を選択します。

4.保持しているセキュリティグループのインバウンドルールを全て確認します。送信元0.0.0.0/0からの該当ポートへのインバウンド許可ルールがある場合、[インバウンドルールを編集]をクリックします。

5.[インバウンドルールを編集]画面にて、特定した接続元IPからの該当ポートへのインバウンド許可ルールを追加します。追加後、[変更をプレビュー]をクリックします。

6.接続元IPからの該当ポートへのインバウンド許可ルールのみ追加されていることを確認します。確認後、[変更を保存]をクリックします。

7.セキュリティグループに属しているAWSリソースへの接続確認を実施します。接続元IPアドレスから該当ポートで接続できることを確認します。

※ 全ステークホルダーが接続確認を行なって下さい。

3. 設定削除

1.[2. 設定追加]で変更したセキュリティグループを選択します。
2.[インバウンドルールを編集]をクリックします。

3.[インバウンドルールを編集]画面にて、送信元0.0.0.0/0 からの該当ポートへのインバウンド許可ルールを削除します。削除後、[変更をプレビュー]をクリックします。

4.送信元0.0.0.0/0 からの該当ポートへのインバウンド許可ルールのみ削除されていることを確認します。確認後、[変更を保存]をクリックします。

5.セキュリティグループに属しているAWSリソースへの接続確認を実施します。接続元IPアドレスから該当ポートで接続できることを確認します。

※接続不可だった場合、接続元IPアドレスの指定が誤っている可能性があります。そのため、下記の[4.切戻手順]を実施します。

4. 切戻手順

1.「[3.設定削除]で変更したセキュリティグループを選択します。 2.[インバウンドルールを編集]をクリックします。

3.[インバウンドルールを編集]画面にて、送信元0.0.0.0/0からの該当ポートへのインバウンド許可ルールを追加します。追加後、[変更をプレビュー]をクリックします。

4.送信元0.0.0.0/0からの該当ポートへのインバウンド許可ルールのみ追加されていることを確認します。確認後、[変更を保存]をクリックします。

5.セキュリティグループに属しているAWSリソースへの接続確認を実施します。接続元IPアドレスから該当ポートで接続できることを確認します。
6.再度、ステークホルダー間で接続元IPアドレスを確認し、[2. 設定追加][3.設定削除]を実施して下さい。

最後に

今回は、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修正手順をご紹介しました。

コントロールを修正して、お使いのAWS環境のセキュリティをパワーアップさせましょう!

最後までお読みいただきありがとうございました!
どなたかのお役に立てれば幸いです。

以上、おつまみ(@AWS11077)でした!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.